From: Joey Hess Date: Sat, 22 Mar 2025 13:23:00 +0000 (-0400) Subject: todo X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~6^2~60 X-Git-Url: https://dgit.raspbian.org/%22http://www.example.com/cgi/%22/%22http:/www.example.com/cgi/%22?a=commitdiff_plain;h=0bc1bebe051bfe0822aa14d7b0fdc0139d8b94e0;p=git-annex.git todo --- diff --git a/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn b/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn new file mode 100644 index 0000000000..4d29f2e5ba --- /dev/null +++ b/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn @@ -0,0 +1,24 @@ +I tried a cluster where each node was in the archive group. Sending to the +cluster caused the file the end up on multiple nodes, though the preferred +content should have allowed it to be stored on only one. + +This is because a cluster checks preferred content for each node and sends +to all nodes that want it. Which works fine when using balanced preferred +content expressions, but for archive, they all want it until 1 has it. + +So to support archive better, after finding a node that wants the content, +when checking the second node it would need to check its preferred content +under the assumption that the first node already contains the content. And +so on. Currently this is not supported when checking preferred content, but +something similar is done when dropping, with a set of repos to assume +don't contain the content any longer. + +(Oddly, in my case, it seemed to always end up on 2 nodes out of 4, I don't +know why it didn't also get sent to the other 2.) + +(Not considering this a bug, because cluster was designed to be used with +balanced preferred content, which will probably work better in many ways. +Still it would be good to support this, especially for when existing +archive repositories get put in a cluster.) + +--[[Joey]]